Added a FastMCP example that shows how to send log messages and progress reports back to the client during tool execution.

The new example is examples/fastmcp/logging_and_progress.py. The tool function receives a context argument and calls its .info() and .report_progress() methods. It is based off of simple_echo.py; I copied that example, and added to the tool function a context argument, logging, and progress reporting.

Motivation and Context

As a total newbie, I had a little trouble getting the context argument to receive a value. I couldn't find an example showing how a tool should get the context argument in this repo, and I was slow to realize that I needed to read the FastMCP documentation. Because I hadn't pointed it to the FastMCP documenation, Claude Code generated a declaration for the context argument that didn't work (it typed the context argument as Optional, which understandably causes the SDK not to recognize the argument as the context argument). Seems obvious in retrospect, but it wasn't obvious to me at first.

I also learned while testing of the potential race condition with notifications sent near the end of a tool call: Since the client SDK code (src/mcp/shared/session.py) processes progress notifications asynchronously, if the tool function returns very soon after the final call to report_progress, the client doesn't reliably receive that final progress update. Adding the final sleep helps ensure the client will process the final progress update. I assume this is intended behavior but hope that the sleep in the example might draw users' attention to something they should probably be aware of.

How Has This Been Tested?

I have tested equivalent lines of code in the MCP server and client I am developing, and I have tested the new example (MCP server) using modelcontextprotocol/inspector.

Breaking Changes

None.

Types of changes

It simply adds one example code source file.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling [I believe I have successfully followed simple_echo.py's lead on this and added no error handling.]
• I have added or updated documentation as needed [I believe I have successfully followed simple_echo.py's lead on this and added no documentation.]

Additional context

Hopefully I got this right; happy to adjust if I didn't.